1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. connect
  4. Issues

Add Security Considerations for Cross-device SIOP

Issue #1269 resolved
Kristina Yasuda created an issue

A very thorough Security Considerations section is needed for Cross-device SIOP model (SIOP and RP on different devices), since it has different security considerations than “same-device“ SIOP and potentially opens up new attack surface that implementors should be warned against.

Comments (14)

  1. Stephane Durand

    Can we clarify what are the threats considered?

    • Phishing is one, where the end user could be mislead to disclose their personal information to a different party than intended.

    • In a more elaborate scheme, phishing could lead to identity theft, as the attacker synchronizes the phishing part with the consumption of the stolen data with a service.

      • Such case of relay attack has been considered in mobile payments and mitigated with timing counter-measure (these may be protected methods)

    • Other case?

    From a security perspective, I am somehow failing to see how being cross device is much different from being on the same device: anything between the SIOP and the RP is to be considered as attacker playground, and does it really matter whether the playground is a yard or a mile long as long as the security is treated from endpoint to endpoint?

    As sub bullet, while we could consider the RP is a public client on a device (same or different), I think that we are rather considering cases where the RP is a form of service provider, seating in a server. Maybe the question is more about the type of oidc client we are dealing with and how the communication is transported between the RP and and the SIOP end than whether the device is the same or not? To illustrate this, do we consider a device-local communication channel on a rooted device more secure than a TLS with pinned certificate to a remote server?

    For me, the way to address the phishing concern is to make sure we can present the end user with a trusted identity of the RP. A quite appropriate approach is to rely on request_uri parameter, which is carried over https (we still get into the issue of how can we control the identity claimed by the host, but I think that is more something that should be addressed by other operational aspects of a Trust Framework – EU eIDAS amendment proposition highlights for instance that RP that intend to interact with the proposed European Digital ID Wallet need to engage with National Authorities first; that could lead to acquisition of a QWAC certificate). It’s currently not listed as supported by SIOP (as opposed to request), but I kind of recall seeing an issue (or maybe even a PR) addressing it.

  2. Kristina Yasuda reporter

    Hi Stephane, please checkout the notes from the two SIOP calls where we discussed in detail security features we want to prevent:

    In short, a 'session phishing' attack caused by the lack of bi-directional channel binding is the biggest concern. Cryptographic signature on Verifiable Presentation does not help, encryption does not help, and redirect happening to the website on the device (rather than on a desktop) does not help having the user authenticate at the browser using a usual OIDC flow, set a signed cookie tying userID, browser and the RP, start a SIOP flow and have SIOP include userID in the SIOP response for the RP to validate is a potential mitigation could, but does not work if the initial cookie is tied to a malicious website. Because the core problem is that SIOP still has no idea which origin is presenting the QR code.

    The core question becomes how do you trust the browser on the consumption device (RP). Current most promising mitigation seems to be wallet on the consumption device creating a WebAuthn credential, using it for re-authentication at the consumption device. We opened an issue to start writing it up. Issue #1273

    ‌

  3. Stephane Durand

    Thank you Kristina,
    The Pacific meetings are a bit difficult for me to attend so this helps.

    I've spun it around for some time and I actually wonder if some of these security concerns don’t fall out of the scope (or at least out of the reach) of an OIDC spec.
    It's just that the SIOP and the client don't know each other and I think it's not an issue of access channel but rather due to the fact that both the SIOP and the client cannot be authenticated as a specific entity (in the sense that they expect it to be XYZ from some prior knowledge/agreement) by each other.
    With 'regular' OP, TLS certificate (possibly pined to prevent MITM) as well as client registration (unless it is open) create the conditions for mutual authentication.
    With SIOP, the OP is sort of "anybody" and the client is registered on the spot.

    The problem goes in both directions:
    a) The SIOP cannot make sure of the client's identity and the user may be sharing their data with someone else
    b) The client cannot make sure of the SIOP's identity and the client may be getting someone else's identity

    For a), we could define a new class of 'identifiable' clients that are capable to provide evident identity information to the OP. ('confidential' clients are capable to authenticate themselves; here, it is desirable that the client is able to provide its own, verifiable, identity information).
    Then, we should take the assumption (or express the requirement) that only 'identifiable' clients will (may) engage with SIOP. The SIOP would be able to validate the identity and present it to the end user and this would address the concern that the user can be fooled into disclosing their information to a random someone else.
    As practical implementation of identifiable property, I believe having client that includes a https hosted part, hosting the request object on this part and issuing the authorization request with a request_uri parameter enables the SIOP to validate and present the identity of the server to the user, as described in my previous post.

    For b), when the session starts, the client doesn't know who is the (SI)OP, and doesn't even have the pretention to know it. It just want to reach 'a' SIOP that will be able to answer its request.
    The expectation rather come from the use case. For the NHS example, the kiosk expects that the doctor's badge SIOP answering to it is the one facing the kiosk. Isn't it more relevant that the 'proximity' expectation is solved by the proximity engagement method?
    The required proof is a 'proximity' proof, which is part of the 'analog' world and must therefore be addressed in this domain (for instance, timing measurements to try and detect that there was a relay between the parties). I don't see how SIOP can cover that domain or provide some relevant substitute for such proof.
    Besides, the way to address such 'proximity' (or 'attachment') proof probably depends on how the engagement is done (QR, NFC, UWB, 'type this code', ...).

    I also want to share a few general thoughts on the points from the meeting notes:

    • The threat is not inherent to the consumption device (and whether it is secure or not) but more on the fact that the SIOP cannot be authenticated as a specific entity. I suppose this conclusion came from focusing too much on the QR case: since the QR is visible, tampering between the QR and the SIOP is detectable and ‘therefore’ discarded. As a result, the threat become ‘necessarily' attributed to the agent displaying the QR. If instead we consider NFC, which is not visible, you can imagine a device doing a MITM between a possibly pen-tested and certified agent and the SIOP (and I’m pretty sure such attacks on NFC cards have been prototyped by security researchers).
    • Considering the threat being higher with cross-device than with same-device is a perception but not necessarily a fact. While the attack surface is indeed wider in the former, the latter also allows for mitigations that would need compromising not one but two devices to be bypassed.
    • Coming from payment, I associate "payment terminal" as a point of sales terminal (attended or not), which is used with payment devices (smart cards, smart phones) and I don't really see where the backchannel authn is involved. Is "payment terminal" representing something else here?

    ‌

  4. Kristina Yasuda reporter

    Thank you!

    With 'regular' OP, there is also binding between client_id and redirect_uri, and there is a proposal to introduce it in Issue #1272, which might be similar to your proposal in a)?

    As practical implementation of identifiable property, I believe having client that includes a https hosted part, hosting the request object on this part and issuing the authorization request with a request_uri parameter enables the SIOP to validate and present the identity of the server to the user, as described in my previous post.

    For b) we have a SIOP chooser issue (#1212), and there is a text in the SIOP v2 on this matter that I think addresses the concern? https://openid.bitbucket.io/connect/openid-connect-self-issued-v2-1_0.html#name-self-issued-openid-provider

  5. Stephane Durand

    Relying on redirect_uri is similar (provided https is used) but I feel it is weaker than using request_uri. With request_uri, the request can be considered only after the requester identity has been somehow validated so the request can be trusted. With redirect_uri, the SIOP/user can only validate to whom it will send the response, but have no assurance on the request. For instance an attacker could alter the request so that redirect_uri is http instead of https. To the SIOP, it would still look like the other party is the correct one, but the attacker could easily intercept / eavesdrop the response.

    ‌

    The chooser is about letting the user or the RP chose which SIOP they want to use from the many that are present on their mobile device. And there, “which SIOP” is like a class determination, based on brand, personal preference, trust framework recognition…

    Here, beyond which ‘class’ of SIOP is used, the concern is more about how the RP can be sure it’s talking to the ‘instance’ it expects.

  6. Kristina Yasuda reporter

    after the requester identity has been somehow validated

    yes, how to validate requested identity is the core issue here.

    redirect_uri tied with client_id is hard to be altered

    I am not sure RP can be expected to be talking to a particular instance in SIOP case - hence the information you can get during the SIOP chooser process becomes the OP discovery information.

    ‌

  7. Kristina Yasuda reporter

    On 08-05-2021 call, we agreed to add the following security considerations related to the kiosk use-case:

    “In the kiosk use-case there are two systems - 1/between SIOP and backend; and 2/user and the kiosk, and that we don't really have ways to authenticate the latter securely. So it is not guaranteed that the user in front of the kiosk is the owner of the credential presented. To ensure this, some transitive authentication is needed. With FIDO, it will look like: make a resident credential with the backend in the browser on your phone, use CABLE over BLE or local NW to do FIDO authentication from your phone through the terminal to authenticate you in that other session. Or in the presented credential contains biometric data, kiosk can use local biometrics to scan your face or biometrics to match with the data in the credential” details are in the minutes.

  10. Stephane Durand

    In last Atlantic call on SIOP, we discussed at length about SIOP not being for authentication and I think there is a consensus around this.
    However, I felt that the limitation was, in the way it was discussed, very much tied to the cross device configuration of SIOP use and I think this is not correct. The point I tried to convey during the call, and I am not sure I did it with enough clarity, is that the issue is in my opinion rather related to the fact that we cannot identity and authenticate the SIOP as a specific identity provider rather than the way it is reached.
    I'll try to elaborate further here.

    As a relying party, I want to identify an end user and I will rely on an OP to do it for me. This is valid as long as the OP is relevant to authenticate the end user and I can authenticate the OP. It's a transitivity principle we have mentioned in call.

    With Connect, I am turning to an OP which I trust as an entity (and possibly but not only on its capacity) to identity and authenticate the end user and provide me back with their identity. To map it to a concrete example, the OP may be THE tax office (and not a tax office).
    I have means to validate its identity as THE tax office because the TLS connection (whose support is mandated by OIDC and I which I chose as client) provides me with the OP's certificate carries its identity (within a trust framework that I recognize) and binds this identity with the data I receive from the OP.

    With SIOP, I actually don't know who the OP is. At best, I will know that the OP is relevant to authenticate the end user: we may share a common trust framework and the OP would get some attestation from this trust framework. However, these attestation will be on the capacity of the SIOP and not on its identity.
    While an identity request with Connect is like going to the tax office desk to ask the question, with SIOP, it is like shouting the question in the dark. Even if the room is full of people that are qualified to answer, we don't know who is answering. And that is quite important because an underlying trait of SIOP is that it is relevant to authenticate a single end user only (I don't know if that is a required or implied trait but this is certainly one that's influencing our view of SIOP).

    We are probably all in line so far.

    Now, I think the discussion has drawn a line between same device and cross device use of SIOP that actually doesn't exist.
    I guess it is driven by a perception that when on the same device, we know who the SIOP is because (supposedly) this is the (supposedly and which one in particular?) one running on the device.
    While the physical separation of cross devices makes the possibility of not talking to the SIOP we expect to more palpable, the possibility is also there when on same device. For one thing, discussion on the SIOP Chooser highlighted the lack of determination as one of the flaw of the openid: scheme approach.
    Even on same device, you can have MITM attacks that misconnect the request from one legit SIOP to another legit SIOP to power a session-phishing (or whatever other name) attack.
    Admittedly, the surface of attack with cross device is larger, but what we really have to consider is that, inherently, SIOP specification just doesn't have mechanisms to identify (or I missed it and it was also not brought up during the security discussions) the SIOP entity from the RP perspective. For that reason, it would be misleading to just say that SIOP-CD is not suitable for authentication, and implicitly let the reader believe that SIOP-SD is fine.

    If we want to propose a solution, we need to figure a way to authenticate a SIOP in a way that is first: meaningful for the RP and then: inherent to the SIOP (not assuming properties on its environment - or be clear about it). Indeed, RP is expecting to talk with a given SIOP and validating this RP expectation is the key to authenticate the SIOP:

    • in SIOP-SD, the RP expects the SIOP to be on same device: SIOP needs to prove it to be so (there are device fingerprinting methods but not authoritative and in conflict with privacy-preserving intentions)
    • in SIOP-CD, the RP expects the SIOP to be ... in direct proximity. It's a more open problem because a wider variety of bearers may be involved and the 'direct proximity' might need to be characterized in view of the specific bearer.

    ‌

  11. Kristina Yasuda reporter

    Thank you, Stephance for a very thoughtful comment:

    If we want to propose a solution, we need to figure a way to authenticate a SIOP in a way that is first

    Since SIOP is controlled by the user, what would “authenticate a SIOP“ actually mean? Does it mean the need to pass information about the provider of a SIOP, like an attestation information in FIDO? and potentially have an organization or trust framework maintain an “trusted“ list of those attestations?

    We had this conversation in the context of iss=self-issued.me, when we were considering to put such attestation information in iss field. But because there was no way to prove the “trust“ in such attestation without any trust framework like mechanism and because inherently iss=self-issued.me draws a line between other OIDC flows telling RP it is a SIOP chosen by the user presenting a credential, we decided to leave self-issued.me for now, if I remember correctly. https://bitbucket.org/openid/connect/issues/1208/siop-v2-dynamic-iss-claim-ref-required

    ‌

  13. David W Chadwick

    Kristina said “Cryptographic signature on Verifiable Presentation does not help”. Actually it can help as follows. If the  request_uri parameter is copied by the wallet into the presentation before it is signed and converted into a VP, then the RP can tell whether the VP was destined for itself or not. A MITM that tries to use the VP to access the true RP by masquerading as the user, would see that the request_uri parameter identifies the MITM and not itself, so would reject the VP and the MITM’s access request

  15. Log in to comment
Assignee
Type
bug
Priority
major
Status
resolved
Component
SIOP
Milestone
–
Version
–
Votes
0
Watchers
3
Jira: the preferred issue tracker for Bitbucket. Join the team!